-
Notifications
You must be signed in to change notification settings - Fork 476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add batteryLevel to matter sensor #1863
Conversation
Duplicate profile check: Warning - duplicate profiles detected. |
Channel deleted. |
Test Results 64 files 408 suites 0s ⏱️ Results for commit e84deec. ♻️ This comment has been updated with latest results. |
Minimum allowed coverage is Generated by 🐒 cobertura-action against e84deec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -157,8 +154,10 @@ local function do_configure(driver, device) | |||
profile_name = profile_name .. "-leak" | |||
end | |||
|
|||
if supports_battery_percentage_remaining(device) then | |||
if battery_supported == battery_support.BATTERY_PERCENTAGE then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just moving this comment over from the previous mega PR since I don't think it has been resolved yet:
I believe there is a confluence page somewhere that indicates the expected order of capabilities in a profile. I cannot seem to find it, but I believe @hcarter-775 might have updated it somewhat recently.
Anyway, in a similar vein, we should document the expected order of our profile name tags so that when we are creating new profiles, we can ensure that their name are internally consistent. For example, this function essentially outlines the order I am talking about (motion is first, contact is second...preferences are last). This way it is clear the order of precedence when using all these combinations of flags to create the profile name.
@hcarter-775 do you know where this confluence page that has the capability ordering documented is located? I believe we had looked at it together during the 1.3 stuff but I do not remember where it was so I am wondering if you remember?
@nickolas-deboom can you fill out the "Summary of Completed Tests" section as well? Are there any real devices this can be tested against that we have in the office? |
I have a battery-powered Eve weather device that I can test out tomorrow! |
Type of Change
Checklist
Description of Change
CHAD-12161
Matter drivers currently assume that
BatPercentRemaining
is available if theBAT
feature is supported, but this attribute is only optionally required if this feature is present. The changes in this PR improve the profile selection logic in matter-sensor by reading theAttributeList
, checking ifBatPercentRemaining
orBatChargeLevel
is available, and then profiling the device as needed.Note that these changes were originally in PR 1796 but this PR was split up into 5 separate PRs, one for each affected driver.
Summary of Completed Tests
Tested with a Contact Sensor device. This device supports
BatPercentRemaining
and so is profiled tocontact-battery
. See the relevant logs below: